home *** CD-ROM | disk | FTP | other *** search
/ PsL Monthly 1993 December / PSL Monthly Shareware CD-ROM (December 1993).iso / prgmming / dos / c / chkseg.com / CHKSEG.DOC < prev    next >
Encoding:
Text File  |  1988-11-16  |  4.7 KB  |  89 lines
  1.                        CHKSEG (Check Segment Structure)
  2.  
  3. CHKSEG is a utility program which may be used to check the segmentation
  4. structure of an overlayed program.  Basically, this program will tell you which
  5. procedure calls, in segments other than the root, cause other segments to be
  6. loaded.  Only one level of segmentation is supported in this program although
  7. the source could be modified to support multiple levels of segmentation.  In
  8. addition, only programs which are written in 'C' are accomodated because of the
  9. manner in which CHKSEG was written.
  10.  
  11. CHKSEG should be compiled using the large data model (compact, large, huge)
  12. with a command line similar to the following:
  13.  
  14.    cl /c /AL chkseg.c
  15.  
  16. It should then be linked with a stack size of about 32000 bytes.  The large
  17. stack size is required because of the recursive nature of some of the
  18. procedures within the program.
  19.  
  20.    link/ST:32000 chkseg;
  21.  
  22. CHKSEG operates in the following manner:
  23.  
  24.    1.   It first asks for and then reads the segmentation directives which you
  25.         would normally give to the MSC link module.  That is, if you link a
  26.         program with the following command line:
  27.  
  28.             link/<switch>/... @load
  29.  
  30.         'load' is the file that CHKSEG would read.  The 'load' file would
  31.         normally contain object file names with '+'s in between them and
  32.         parenthesis to indicate segments.  The format is exactly as indicated
  33.         in the MSC manual for specifying overlays/segments to link.
  34.  
  35.    2.   CHKSEG then asks for the name of a file on which to write the results
  36.         of it's checking.  This file will contain a trace (listing of the
  37.         procedure calling heirarchy) of the procedure calls which result in a
  38.         segment being loaded that is not in the calling heirarchy.
  39.  
  40.    3.   Next, CHKSEG asks for a file template (actually, a path specification
  41.         which usually contains wild characters) which provides all the 'C'
  42.         procedures which are used in the segmented program.  If not all of the
  43.         procedures are kept in one directory, there is a chance to specify
  44.         another template.  CHKSEG uses this template to build a cross-reference
  45.         table for all the 'C' files/procedures which are involved.  An
  46.         assumption is made that the file names for the object files are the
  47.         same as those for the 'C' files except for the extension.
  48.  
  49.    4.   After building all cross-references to the 'C' procedures, CHKSEG will
  50.         ask the user for the maximum call depth to check.  This essentially is
  51.         the number of levels of 'who-calls-who' that CHKSEG will go to detect
  52.         procedures which are not in the calling heirarchy.  The higher the
  53.         number, the more time it will take CHKSEG to perform checking.  A value
  54.         in the range 12-15 is normally O.K.
  55.  
  56.  
  57.    5.   CHKSEG will then begin segment checking.  For each procedure in each
  58.         segment, it will determine all the procedures that are called by that
  59.         procedure and check to insure the called procedures are either in the
  60.         same segment or are in the root segment.  Files which were not
  61.         specified in the load specification are assumed to be loaded in the
  62.         root (this is what MSC link does).  If everything is O.K., CHKSEG then
  63.         goes to the next calling level down (all the procedures which are
  64.         called by the starting procedure) and performs the same analysis on
  65.         them.  This can continue for the maximum number of levels indicated in
  66.         4. above.  If a procedure is detected that is not in the calling
  67.         heirarchy, a trace back of procedure calls is written to the file
  68.         indicated in step 2. above. 
  69.  
  70. This program takes a while to run if you have a rather large program that you
  71. are checking.  It is not as smart as it could be in performing checks (e.g., if
  72. it has checked a procedure A that calls B that calls C, it will check B's
  73. heirarchy also if it encounters B as the starting procedure).  However, I
  74. didn't bother to enhance it since I only use this program occasionally and the
  75. time to run it isn't that big of a factor.
  76.  
  77. A probably better implementation of this program would be to read the object
  78. files instead of the source files for cross-reference purposes.  This would
  79. allow for any language to be used on the source as long as the object file
  80. format was the same.  I didn't do it that way because it was easier to modify a
  81. 'C' cross-reference program that I had rather than to write a new object cross-
  82. reference program.  Oh, well.
  83.  
  84. Any comments, corrections, etc. that you have would be appreciated.
  85.  
  86.               Willard Gersbacher  CompuServ ID: [76117,2611]
  87.  
  88.  
  89.